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DETAILED ACTION 
Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.1 14, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 8/05/2010 has been entered. 

Response to Arguments 

2. Applicant's arguments, filed 8/05/2010, with respect to objection of the specification, 
rejection based on non- statutory obviousness-type double patenting, and rejections under 35 
use 101 have been fully considered and are persuasive. These objections/rejections have been 
withdrawn. 

3. Applicanfs arguments with respect to claims 1-10, 12-29,31-39,42-50,54-56 and 58-65 
have been considered but are moot in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 
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5. Claims 1, 2, 3, 5, and 12 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc (US 6.463.062) in view of Gai (US006 167445 A) in view of Ise et al (US 6,999,419 
B2). 

Regarding claim 1, Buyukkoc discloses a method in an synchronous Transfer Mode 
(ATM) network (see FIG. 7-9, a method performed by central Routing Status Database server, 
RDS in ATM network; see col. 19, line 55-60) having an ingress switch (see FIG. 9, ATM 
switch 922) and an egress switch (see FIG. 9, ATM switch 924), wherein the ingress switch 
serves an ingress device (see FIG. 9, switch 912) operated by a calling party (see FIG. 9, User 
902) and the egress switch serves an egress device (see FIG. 9, Switch 914) operated by a called 
party (see FIG. 9, user 904); see col. 19, line 61 to col. 20, line 24), the method comprising: 

receiving, in the ingress switch, a signaling message from the ingress device (see FIG. 9, 
step 810, edge node receive anew call; see col. 19, line 19-26; also see FIG. 10, step 1005, 1010, 
1015, 1020, 1025, 1030; see col. 20, line 50-67); 

providing the signaling message to a signaling intercept processor (see FIG. 7, a link 750 
to Regional RSD server, RRSD, 740; see col. 13, line 22-46) associated with the ingress switch 
(see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 19, line 25-30; edge node send a call 
query/message to RSD; also see FIG. 10, step 1035); 

propagating the signaling message from the signaling intercept processor to a policy 
server (see FIG. 7, from regional RSD 740 (RRSD) via a link 770 to central RDS server 730, i.e.. 
Signaling Control Point, SCP), 
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the policy server being associated with a policy profile database (Tables VII-IX, RSD 
associated with a database), 

the policy profile database storing entries that relate subscriber to policies (see col. 14, 
line 9 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29- 
67; RSD stores contents consists call/connection rules/policies (e.g. features/description includes 
connectively information, threshold, quality of service, capacity, and/or status of 
loading/congestion), where a call is associated with a user/subscriber since the user/subscriber is 
the one making the call/connect), 

where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of service 
feature/description of a group of features/descriptions connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber); 

Identifying in the policy profile database and based on the signaling message, a policy for 
the calling party (see col. 17, line 25 to col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
recognizing/identifying a specific rule/policy in the RSD rule/policy database tables VII-IX); 
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determining, in the policy server and based on the signaling message, that the policy for 
the calling party is to be enforced (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; 
see col. 11, line 1-16; see col. 13, line 1-6, 29-67; Tables VII-IX; according to a new call in the 
RSD database tables, deciding/determining a specific rule/policy to trigger/apply to received 
call's priority of traffic); 

executing, in the policy server and based on the signaling message for each policy feature 
of the one or more pohcy features identified by the policy for the calling party (FIG. 8, step 840; 
see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to 
col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; 
according to a new call, processing/executing in RSD for each status/feature (i.e. connectively 
information, threshold, quality of service, capacity, or status of loading/congestion) of a group of 
status/feature/priority (i.e. connectively information, threshold, quality of service, capacity, and 
status of loading/congestion) identify/recognized by the rule/policy associated with a 
call/connection for the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
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is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 

where one ore more policy features, identified by the policy for the calling party, 
comprises an aggregated bandwidth limit feature (see col. 17, line 30-40; see col. 13, line 45-47; 
total bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow. Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

calculating bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determining whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, 
step 840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 
25- to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 
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determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps); 

establishing a connection path between the ingress switch and the egress switch based on 
the determination that the policy condition is satisfied for each policy feature, of the one or more 
policy features identified by the policy for the calling party (see FIG. 8, step 850, 860, 870; see 
FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 
40-50; setting/establishing the call/connection when load/congestion/priority/bandwidth/routes 
conditions/status (i.e. connectively information, threshold, quality of service, capacity, or status 
of loading/congestion) are met/fulfilled for each policy/rule status/feature identified/recognized 
by the user/subscriber policy). 

Although Buyukkoc discloses executing in the policy server for each policy feature of the 
one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose ''appropriate service logic". 

However, Gai teaches the policy server (see FIG. 4, policy server 322) being associated 
with a policy profile database (see FIG. 4, a combined system of database policy rule 414, policy 
translator, repository 326 and device-specific filtering entity 416), the policy profile database 
storing entries that relate subscriber to policies (see FIG. 4, stores data related to user policies; 
see col. 13, line 61 to col. 14, line 5), where each policy defines one more policy features of a 



Application/Control Number: 09/766,943 Page 8 

Art Unit: 2463 

group of policy features with which the related subscriber is associated (see FIG. 4, each policy 
defines rules/policy features for a group of policy features (e.g. source address screening, 
Destination address screening features) for each user; see col. 14, line 1-15, 56 to col. 15, line 
55); 

identifying, in the policy profile database, a policy for the calling party (see FIG. 4, 
identifying/recognizing the pohcy for a calling user in the combined database system; see col. 
13, line 60 and col. 18, line 65); 

Determining, in the policy server and that the policy for the calling party is to enforced 
(see FIG. 4, determining the pohcy for the caller/user is to be managed/restricted/enforced in the 
policy server 322; see col. 13, line 60 and col. 18, line 65);; 

executing in the policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; combined 
bandwidth processing) and 
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wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 

determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 
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determining that the condition is satisfied for the aggregate bandwidth limit feature when the 
calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 to 
col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA); 

establishing the connection path based on said determination that the policy condition is 
satisfied for each policy feature, of the one or more policy features identified by the policy for 
the calling party (see FIG. 4, establishing a connection/communication base on determination 
that pohcy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized 
by the policy of the caller/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide ''appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service pohcies; see Gai col. 5, line 45-55. 

Buyukkoc and Gai do not exphcitly disclose 

identifying an available forward bandwidth from the ingress switch to the egress switch, 
identifying an available reverse bandwidth from the egress switch to the ingress switch, 
calculating a first requested bandwidth associated with the first signaling message, where the 
first requested bandwidth includes a first forward requested bandwidth from the ingress switch to 
the egress switch and a first reverse requested bandwidth from the egress switch to the ingress 
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switch, 

calculating a second requested bandwidth associated with the second signaling message, where 
the second requested bandwidth includes a second forward requested bandwidth from the ingress 
switch to the egress switch and a second reverse requested bandwidth from the egress switch to 
the ingress switch, 

determining that the available forward bandwidth exceeds the first forward requested bandwidth 
and that the available reverse bandwidth exceeds the first reverse requested bandwidth, 
determining an occurrence of at least one of: 

a total forward requested bandwidth, including the first requested forward bandwidth and the 
second requested forward bandwidth, exceeds the available forward bandwidth, or 
a total reverse requested bandwidth, including the first requested reverse bandwidth and the 
second requested reverse bandwidth, exceeds the available reverse bandwidth, determining that 
the pohcy condition is satisfied for the aggregate bandwidth limit feature for the first signaling 
message, and 

determining that the policy condition is not satisfied for the aggregate bandwidth limit feature for 
the second signaling message, and 

forwarding, to the ingress device, a connection failure notice related to the second signaling 
message. 

Ise discloses 

identifying an available forward bandwidth from the ingress switch to the egress switch (column 
4 lines 61-67 remaining resources on route from ingress to egress node). 
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identifying an available reverse bandwidth from the egress switch to the ingress switch (Figure 
18 and column 18 lines 62-67 egress edge node transmits the remaining bandwidth), 
calculating a first requested bandwidth associated with the first signaling message, where the 
first requested bandwidth includes a first forward requested bandwidth from the ingress switch to 
the egress switch and a first reverse requested bandwidth from the egress switch to the ingress 
switch (column 4 lines 30-52 shows carrying out admission control for a request for allocation of 
resources for a flow belonging to a set of flows i.e. multiple signaling messages and the request 
for resources is the bandwidths), 

calculating a second requested bandwidth associated with the second signaling message, where 
the second requested bandwidth includes a second forward requested bandwidth from the ingress 
switch to the egress switch and a second reverse requested bandwidth from the egress switch to 
the ingress switch (column 4 lines 30-52 shows carrying out admission control for a request for 
allocation of resources for a flow belonging to a set of flows i.e. multiple signaling messages and 
the request for resources is the bandwidths), 

determining that the available forward bandwidth exceeds the flrst forward requested bandwidth 
and that the available reverse bandwidth exceeds the flrst reverse requested bandwidth (column 4 
lines 30-52 shows judging whether or not to accept the request according to requested resources 
and available resources, column 4 lines 53-60 shows checking whether the remaining resources 
are sufficient i.e. exceed, column 18 lines 14-21 shows for the reverse path check the egress node 
determines if the reservation is smaller than available resources), 
determining an occurrence of at least one of: 

a total forward requested bandwidth, including the flrst requested forward bandwidth and the 
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second requested forward bandwidth, exceeds the available forward bandwidth (column 4 lines 
30-52 shows judging whether or not to accept the request according to requested resources and 
available resources, column 4 lines 53-60 shows checking whether the remaining resources are 
sufficient i.e. exceed, column 18 lines lines 14-21 shows for the reverse path check the egress 
node determines if the reservation is smaller than available resources, column 18 lines 9-14 
shows the remaining bandwidth would be updated to include the first message when using the 
second), or 

a total reverse requested bandwidth, including the first requested reverse bandwidth and the 
second requested reverse bandwidth, exceeds the available reverse bandwidth, determining that 
the pohcy condition is satisfied for the aggregate bandwidth limit feature for the first signaling 
message (column 4 lines 30-52 shows judging whether or not to accept the request according to 
requested resources and available resources, column 4 lines 53-60 shows checking whether the 
remaining resources are sufficient i.e. exceed, column 18 lines lines 14-21 shows for the reverse 
path check the egress node determines if the reservation is smaller than available resources, 
column 18 lines 9-14 shows the remaining bandwidth would be updated to include the first 
message when using the second) , and 

determining that the policy condition is not satisfied for the aggregate bandwidth limit feature for 
the second signaling message (column 18 lines 14-21 judge whether to accept the request or not 
based on whether the resources are available or not), and 

forwarding, to the ingress device, a connection failure notice related to the second signaling 
message (column 18 lines 61-67). 
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Therefore it would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine the previous combination of Buyukkoc and Gai with the aggregate 
bandwidth limit feature of the forward and reverse direction taught by Ise. 
The rationale to combine would be to determine that the whole route would be able to handle the 
needed bandwidth requirement before accepting the call request. 

Regarding claim 2, Buyukkoc discloses where the signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaIing/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claims 3 and 5, Buyukkoc discloses where the signaling message comprises 
an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a new call 
requesting for a route is the SETUP/adding party message in ATM signaling/SS7; see col. 19, 
line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claims 12, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party comprises a service class selection 
feature (see col. 10, line 50-55; see col. 18, line 26-45; class-of-service) and where the 
determining whether a policy condition associated with each policy feature is satisfied (see FIG. 
8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, 
line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy condition/state (e.g. 
yellow. Red, and green), associated/related with connectively information, threshold, quality of 
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service, capacity, or status of loading/congestion, identified/recognized by the rule/policy 
associated with a call/connection for the user/subscriber is met/fulfilled according to a new 
call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions), comprises: 

determining a requested class of service based on the signaling message 
(determining/checking a requested/demand class of service based on a new call message; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55), 

determining whether the requested class of service is permitted for a customer logical 
port with which the calling party is associated (determine/checking if a requested/demand class 
of service based is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a 
new call; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the service class selection feature when the 
requested class of service is permitted for the customer logical port with which the calling party 
is associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied 
for class of service when the requested/demand class of service is not-blocked (i.e. permitted) for 
a VPI port number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses a service class selection feature (see col. 3, line 5-60; class/type of 
service selection/choosing) and where the determining whether a pohcy condition associated 
with each policy feature is satisfied (see FIG. 4, determining if a policy condition/status 
related/associated with each pohcy/rule feature identified/recognized by the pohcy/rule for the 
caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 



Application/Control Number: 09/766,943 Page 16 

Art Unit: 2463 

determining a requested class of service based on the signaling message 
(determining/calculating a request type/class of service based on request/demand; col. 3, line 5- 
65; see col. 5, line 5-45; see col. 11, line 1 to col. 12, line 40), 

determining whether the requested class of service is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
class/type of service allowed/permitted for a customer/user logical port/connection (i.e. ATM) 
with which the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see 
col. 11, line 1 to col. 12, line 40); and 

determining that the condition is satisfied for the service class selection feature when the 
requested class of service is permitted for the customer logical port with which the calling party 
is associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the caUed/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

6. Claim 4 is rejected under 35 U.S. C. 103(a) as being unpatentable over Buyukkoc in view 
of Gai in view of Ise and further in view of Noake (US006751222B1). 

Regarding claim 4, neither Buyukkoc nor Gai exphcitly disclose a release message see 
FIG. 4, determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65). 
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However, a release message is well know in the ATM signaling/SS7 in order to 
disconnect the call. 

In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 
8, line 9-39). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc and Gai, so that it would make effective use of a band and the respective 
apparatus by transmitting connection information, and by sending/receiving a release message it 
will notify to stop the cell assembling and disassembling processes; see Noake col. 2, line 55-64; 
col. 8, line 19-24. 

7. Claim 7 is rejected under 35 U.S. C. 103(a) as being unpatentable over Buyukkoc in view 
of Gai in view of Ise and further in view of Farris (US006 154445 A). 

Regarding claim 7, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party comprises a call feature (see col. 10, 
line 50-55; see col. 18, line 26-45; call/connection type feature) and where the determining 
whether a policy condition associated with each pohcy feature is satisfied (see FIG. 8, step 840; 
see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; 
see col. 21, line 19-30; determines/decides whether rule/policy condition/state (e.g. yellow. Red, 
and green), associated/related with connectively information, threshold, quality of service, 
capacity, or status of loading/congestion, identified/recognized by the rule/policy associated with 
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a call/connection for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
load/congestion/priority /bandwidth/routes/quality-of-service states/conditions), comprises: 

determining whether the signaling message result for a customer logical port with which 
the calling party is associated (determine/checking if a requested/demand class of service based 
is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a new call; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the call feature when the requested the 
signaling message does not result for the customer logical port with which the calling party is 
associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied for 
type of call when the requested/demand call type is not-blocked (i.e. permitted) for a VPI port 
number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses call feature (see col. 3, line 5-60; class/type of service 
selection/choosing) and where the determining whether a policy condition associated with each 
policy feature is satisfied (see FIG. 4, determining if a policy condition/status related/associated 
with each policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 

determining call type feature based on the signaling message (determining/calculating a 
request call type based on request/demand; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40), 

determining whether the requested call type feature is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
call type allowed/permitted for a customer/user logical port/connection (i.e. ATM) with which 
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the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40); and 

determining that the condition is satisfied for the call type feature when the requested call 
type feature does not result for the customer logical port with which the calling party is 
associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the caUed/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

Neither Buyukkoc nor Gai explicitly disclose "a maximum call attempt rate limit." 

However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "acceptable/maximum specified rate of call attempts", as 
taught by Farris in the combined system of Buyukkoc and Gai, so that it would can detect the 
predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. 

8. Claims 6, 8, 9 are rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc 
in view of Gai in view of Ise, and further in view of Christie'656 (US006690656B1). 

Regarding claims 6, 8, and 9, Buyukkoc discloses where said particular one or more 
policy features, identified by the policy for the calling party, comprises a address validation 
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feature and where the determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) comprises 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address vahdation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 
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Neither Buyukkoc nor Gai explicitly disclose ''within a range of authorized addresses ", 
"when the address, associated with the calling party, is determined to be within the range of 
authorized addresses". 

However, a source address validation/screening is well known in the ATM signaIing/SS7. 

In particular, Christie'656 teaches a source address validation/screening and a destination 
address screening herein where said particular one or more policy features, identified by the 
policy for the calling party, comprises a source address validation feature (see FIG. 7, step 720, 
720, 730; policy/rule validation/verification identify the caller is the caller (source) and called 
(destination) addresses/number/IDs validation; see col. 7, line 5-55; see col. 15, line 30-60) and 

determining whether an address associated with the calling party is within a range of 
authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining whether the caller 
address with within a range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), and 

determining that the condition is satisfied for the source address vahdation feature when 
the address, associated with the calling party, is determined to be within the range of authorized 
addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the status/condition is 
met/accepted/satisfied for the caller ID/number/addresses/ANI associated with the caller is 
determined to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to ''within a range of authorized addresses ", "when the address, 
associated with the calling party, is determined to be within the range of authorized addresses" ., 
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as taught by Christie'656 in the combined system of Buyukkoc and Gai, so that it would can 
validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39- 
45. 

9. Claims 14-16, 18, 31, 39, 42, 43, 45 and 58 14 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Buyukkoc in view of Gai in view of Ise and Smith (US006222823B1). 

Regarding claim 14, Buyukkoc discloses an Asynchronous Transfer Mode (ATM) 
network (see FIG. 7-9, ATM network; see col. 19, line 55-60) for effectuating intelligent policy 
features with respect to a call to be established between a calling party and a called party (see 
FIG. 9, a connection user 904 and 902; see col. 19, line 61 to col. 20, line 24), comprising: 

an ATM switch (see FIG. 9, ATM switch 922) serving a customer premises equipment 
(CPE) operated by the calling party (see FIG. 9, CPE User 902 connects TDM switch 912; see 
col. 19, line 64 to col. 20, line 25); 

a signaling intercept processor (see FIG. 7, Regional RSD server, RRSD, 740; see col. 
13, line 22-46) associated with said ATM switch, the signaling intercept processor to intercept a 
signaling message relative to said call (see col. 47 to col. 14, line 5; see FIG. 8, step 820; see col. 
19, line 25-30; edge node send a call query/message to RSD, thus RSD intercept/capture the call 
query/message; also see FIG. 10, step 1035); 

a policy server (see FIG. 7, central RDS server 730, i.e.. Signaling Control Point, SCP) 
associated with said signaling intercept processor, the policy server being associated with a 
policy profile database (Tables VII-IX, RSD associated with a database), the pohcy profile 
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database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores contents 
consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), where a 
call is associated with a user/subscriber since the user/subscriber is the one making the 
call/connect), where each policy defines one more policy features of a group of pohcy features 
with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of service 
feature/description of a group of features/descriptions connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) where the policy server is to; 

wherein the policy server operates to effectuate a particular policy feature of the plurality 
of policy feature with respect to said call when triggered by the signaling message received from 
said signaling intercept processor (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 
13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; RSD 
determines/decides whether a particular/specific quality-of-service rule/policy of the 
load/congestion/priority/bandwidth/route/quality-of-service condition of a new call/connection is 
met/fulfilled when receiving setup message from a user (via RRSD)). 
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determining that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 18, line 45; 
see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 
13, line 1-6, 29-67; Tables VII-IX; according to a new caU in the RSD database tables, 
deciding/determining a specific rule/policy to trigger/apply to received call's priority of traffic); 

execute for each policy feature of the one or more policy features identified by the policy 
for the calling party (FIG. 8, step 840; see FIG. 10, steps 1035,1040; see col. 17, line 25 to col. 
18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, processing/executing in RSD for each 
status/feature (i.e. connectively information, threshold, quality of service, capacity, or status of 
loading/congestion) of a group of status/feature/priority (i.e. connectively information, threshold, 
quality of service, capacity, and status of loading/congestion) identify/recognized by the 
rule/policy associated with a call/connection for the user/subscriber); 

determine whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 
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a connection path being established when the pohcy condition for each policy feature, of 
the one or more policy features identified by the policy for the calling party, is satisfied (see FIG. 
8, step 850, 860, 870; see FIG. 10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 
35-50; see col. 21, line 40-50; setting/establishing the call/connection when 
load/congestion/priority/bandwidth/routes conditions/status (i.e. connectively information, 
threshold, quality of service, capacity, or status of loading/congestion) are met/fulfilled for each 
policy/rule status/feature identified/recognized by the user/subscriber policy); 

one ore more policy features, identified by the policy for the calling party, comprises an 
aggregated bandwidth limit feature for a particular network port by said calling party (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth; (see FIG. 9, physical trunk/port 932; see 
col. 20, line 1-10; col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link) 

Where, when determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) the policy server is to: 

calculate bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
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19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determine whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, step 
840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- 
to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determine that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps). 

Although Buyukkoc discloses executing in the policy server for each policy feature of the 
one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose ''appropriate service logic". 

However, Gai teaches the policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, the policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 



Application/Control Number: 09/766,943 Page 27 

Art Unit: 2463 

which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening, Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where the policy server is to: 

determine that a pohcy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in the policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

a connection path being estabhshed when the policy condition for each policy feature, of 
the one or more pohcy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, estabhshing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caUer/user; see col. 13, line 60 and col. 18, line 65); 

an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; combined 
bandwidth processing) and 
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wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 

determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 
to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide ''appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service pohcies; see Gai col. 5, line 45-55. 

Neither Buyukkoc nor Gai exphcitly disclose ''authorized for use ". 
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However, determining the maximum bandwidth allowable for a particular port authorized 
for use by said party is well known in the art of ATM. In particular. Smith teaches determining 
the maximum bandwidth allowable for a particular port authorized for use by said party (see 
FIG. 1-2; see col. 9, line 5-45, and abstract; determining predetermined/allowable/authorized 
bandwidth for a particular port/connection of end station). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

Buyukkoc, Gai, and Smith do not explicitly disclose 

identifying an available forward bandwidth from the ingress switch to the egress switch, 
identifying an available reverse bandwidth from the egress switch to the ingress switch, 
calculating a first requested bandwidth associated with the first signaling message, where the 
first requested bandwidth includes a first forward requested bandwidth from the ingress switch to 
the egress switch and a first reverse requested bandwidth from the egress switch to the ingress 
switch, 

calculating a second requested bandwidth associated with the second signaling message, where 
the second requested bandwidth includes a second forward requested bandwidth from the ingress 
switch to the egress switch and a second reverse requested bandwidth from the egress switch to 
the ingress switch. 
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determining that the available forward bandwidth exceeds the first forward requested bandwidth 
and that the available reverse bandwidth exceeds the first reverse requested bandwidth, 
determining an occurrence of at least one of: 

a total forward requested bandwidth, including the first requested forward bandwidth and the 
second requested forward bandwidth, exceeds the available forward bandwidth, or 
a total reverse requested bandwidth, including the first requested reverse bandwidth and the 
second requested reverse bandwidth, exceeds the available reverse bandwidth, determining that 
the pohcy condition is satisfied for the aggregate bandwidth limit feature for the first signaling 
message, and 

determining that the policy condition is not satisfied for the aggregate bandwidth limit feature for 
the second signaling message, and 

forwarding, to the ingress device, a connection failure notice related to the second signaling 
message. 

Ise discloses 

identifying an available forward bandwidth from the ingress switch to the egress switch (column 
4 lines 61-67 remaining resources on route from ingress to egress node), 
identifying an available reverse bandwidth from the egress switch to the ingress switch (Figure 
18 and column 18 lines 62-67 egress edge node transmits the remaining bandwidth), 
calculating a first requested bandwidth associated with the first signaling message, where the 
first requested bandwidth includes a first forward requested bandwidth from the ingress switch to 
the egress switch and a first reverse requested bandwidth from the egress switch to the ingress 
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switch (column 4 lines 30-52 shows carrying out admission control for a request for allocation of 
resources for a flow belonging to a set of flows i.e. multiple signaling messages and the request 
for resources is the bandwidths), 

calculating a second requested bandwidth associated with the second signaling message, where 
the second requested bandwidth includes a second forward requested bandwidth from the ingress 
switch to the egress switch and a second reverse requested bandwidth from the egress switch to 
the ingress switch (column 4 lines 30-52 shows carrying out admission control for a request for 
allocation of resources for a flow belonging to a set of flows i.e. multiple signaling messages and 
the request for resources is the bandwidths), 

determining that the available forward bandwidth exceeds the flrst forward requested bandwidth 
and that the available reverse bandwidth exceeds the flrst reverse requested bandwidth (column 4 
lines 30-52 shows judging whether or not to accept the request according to requested resources 
and available resources, column 4 lines 53-60 shows checking whether the remaining resources 
are sufficient i.e. exceed, column 18 lines 14-21 shows for the reverse path check the egress node 
determines if the reservation is smaller than available resources), 
determining an occurrence of at least one of: 

a total forward requested bandwidth, including the flrst requested forward bandwidth and the 
second requested forward bandwidth, exceeds the available forward bandwidth (column 4 lines 
30-52 shows judging whether or not to accept the request according to requested resources and 
available resources, column 4 lines 53-60 shows checking whether the remaining resources are 
sufficient i.e. exceed, column 18 lines lines 14-21 shows for the reverse path check the egress 
node determines if the reservation is smaller than available resources, column 18 lines 9-14 
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shows the remaining bandwidth would be updated to include the first message when using the 
second), or 

a total reverse requested bandwidth, including the first requested reverse bandwidth and the 
second requested reverse bandwidth, exceeds the available reverse bandwidth, determining that 
the pohcy condition is satisfied for the aggregate bandwidth limit feature for the first signaling 
message (column 4 lines 30-52 shows judging whether or not to accept the request according to 
requested resources and available resources, column 4 lines 53-60 shows checking whether the 
remaining resources are sufficient i.e. exceed, column 18 lines lines 14-21 shows for the reverse 
path check the egress node determines if the reservation is smaller than available resources, 
column 18 lines 9-14 shows the remaining bandwidth would be updated to include the first 
message when using the second) , and 

determining that the policy condition is not satisfied for the aggregate bandwidth limit feature for 
the second signaling message (column 18 lines 14-21 judge whether to accept the request or not 
based on whether the resources are available or not), and 

forwarding, to the ingress device, a connection failure notice related to the second signaling 
message (column 18 lines 61-67). 

Therefore it would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine the previous combination of Buyukkoc and Gai with the aggregate 
bandwidth limit feature of the forward and reverse direction taught by Ise. 
The rationale to combine would be to determine that the whole route would be able to handle the 
needed bandwidth requirement before accepting the call request. 



Application/Control Number: 09/766,943 Page 33 

Art Unit: 2463 

Regarding claim 39, Buyukkoc discloses a computer-readable medium operable with an 
Asynchronous Transfer Mode (ATM) network node (see FIG. 9, ATM switch 922,924 with 
memory 1 104; see col. 22, line 12-40), said computer-readable medium carrying a sequence of 
instructions provided for executing service logic which, when executed by a processing entity 
associated with said ATM network node, (see FIG. 11, see col. 22, line 12-40) causes said ATM 
network node to perform the steps of 

receiving in said ATM network node a signaling message with respect to a call from a 
calling party (see FIG. 9, User 902; see FIG. 9, step 810, edge node receive a new call; see col. 
19, line 19-26; also see FIG. 10, step 1005,1010,1015,1020,1025,1030; see col. 20, line 50-67); 
and 

identifying in the policy profile database associated with the ATM network node and 
based and based on the signaling message, a pohcy for the calling party (see col. 17, line 25 to 
col. 18, line 45; see col. 14, line 9 to col. 15, line 50; see col. 10, line 10-20; see col. 11, line 1- 
16; see col. 13, line 1-6, 29-67; according to a new call, recognizing/identifying a specific 
rule/policy in the RSD rule/policy database tables VII-IX); 

the policy profile database (Tables VII-IX, RSD associated with a database), the policy 
profile database storing entries that relate subscriber to policies (see col. 14, line 9 to col. 15, line 
50; see col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; RSD stores 
contents consists call/connection rules/policies (e.g. features/description includes connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion), where a 
call is associated with a user/subscriber since the user/subscriber is the one making the 
call/connect), where each policy defines one more policy features of a group of pohcy features 



Application/Control Number: 09/766,943 Page 34 

Art Unit: 2463 

with which the related subscriber is associated (see col. 14, line 35-64; each rule/policy 
defines/describes the descriptions/features of connectively information, threshold, quality of 
service, capacity, and/or status of loading/congestion (i.e. a policy/rule for a quality of service 
feature/description of a group of features/descriptions connectively information, threshold, 
quality of service, capacity, and/or status of loading/congestion; a policy/rule for 
loading/congestion feature/description of a group of features/descriptions connectively 
information, threshold, quality of service, capacity, and/or status of loading/congestion) 
associated with a call/connection for the user/subscriber) 

executing, based on the signaling message, for each policy feature of the one or more 
policy features identified by the policy for the calling party (FIG. 8, step 840; see FIG. 10, steps 
1035,1040; see col. 17, line 25 to col. 18, line 45; see col. 13, line 1-7, 64 to col. 15, line 50; see 
col. 10, line 10-20; see col. 11, line 1-16; see col. 13, line 1-6, 29-67; according to a new call, 
processing/executing in RSD for each status/feature (i.e. connectively information, threshold, 
quality of service, capacity, or status of loading/congestion) of a group of status/feature/priority 
(i.e. connectively information, threshold, quality of service, capacity, and status of 
loading/congestion) identify/recognized by the rule/policy associated with a call/connection for 
the user/subscriber); 

determining whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
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information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)); 

one ore more policy features, identified by the policy for the calling party, comprises an 
aggregated bandwidth limit feature for a particular network port by said calling party (see col. 
17, line 30-40; see col. 13, line 45-47; total bandwidth; (see FIG. 9, physical trunk/port 932; see 
col. 20, line 1-10; col. 17, line 30-40; see col. 13, line 45-47; total bandwidth for the port/link) 

Where, when determining whether a pohcy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) the policy server is to: 

calculate bandwidth for the signaling message (see FIG. 8, step 840; see FIG. 10, steps 
1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 
19-30; Table VII, VIII; determining/calculating threshold capacity/bandwidth/Gbps of the 
requested new call/connection), 

determine whether calculated bandwidth exceeds a requested bandwidth (see FIG. 8, step 
840; see FIG. 10, steps 1035, 1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- 
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to see col. 21, line 30; Table VII, VIII; determining/calculating the determined/calculated 
threshold capacity/bandwidth/Gbps with threshold capacity/bandwidth/Gbps is higher/exceed the 
requested/required capacity/bandwidth/Gbps), and 

determine that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 14, line 
10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table VII, VIII; ; determining 
that the condition/status (i.e. red/yellow) for the total bandwidth feature when the 
determined/calculated threshold capacity/bandwidth/Gbps is not higher/exceed the 
required/requested capacity/bandwidth/Gbps); 

upon determining that the policy condition associated with each policy feature of one or 
more policy feature identified by the policy for the calling party is satisfied with respect to the 
signaling message (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 
to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions)), causing a connection path to be 
established between the calling party and the call party (see FIG. 8, step 850, 860, 870; see FIG. 
10, steps 1045, 1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call/connection when load/congestion/priority/bandwidth/routes 
conditions/status (i.e. connectively information, threshold, quality of service, capacity, or status 
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of loading/congestion) are met/fulfilled for each policy/rule status/feature identified/recognized 
by the user/subscriber policy). 

Although Buyukkoc discloses executing in the policy server for each policy feature of the 
one or more policy features identified by the policy for the calling party as set forth above, 

Buyukkoc does not explicitly disclose ''appropriate service logic". 

However, Gai teaches the policy server (see FIG. 4, policy server 322) being associated 
with said intercept processor, the policy server being associated with a policy profile database 
(see FIG. 4, a combined system of database policy rule 414, policy translator, repository 326 and 
device-specific filtering entity 416), the policy profile database storing entries that relate 
subscriber to policies (see FIG. 4, stores data related to user policies; see col. 13, line 61 to col. 
14, line 5), where each policy defines one more policy features of a group of policy features with 
which the related subscriber is associated (see FIG. 4, each policy defines rules/policy features 
for a group of policy features (e.g. source address screening. Destination address screening 
features) for each user; see col. 14, line 1-15, 56 to col. 15, line 55) where the policy server is to: 
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determine that a policy in the policy profile database is to be enforced for the calling 
party (see FIG. 4, determining a policy for the caller/user in the combined database system is to 
be managed/restricted/enforced for caller user; see col. 13, line 60 and col. 18, line 65); 

execute in the policy server appropriate service logic for each policy feature of the one 
ore more policy feature identified by the policy of the calling party (see FIG. 4, 
executing/processing specific engine/logic for each policy feature identified by the policy of 
caller/user; see col. 13, line 60 and col. 18, line 65); 

determining, whether a policy condition associated with each policy feature, of the one or 
more policy features identified by the policy for the calling party, is satisfied (see FIG. 4, 
determining if a policy condition/status related/associated with each policy/rule feature 
identified/recognized by the policy/rule for the caller/user is accepted/satisfied; see col. 13, line 
60 and col. 18, line 65); 

an aggregated bandwidth limit feature (see col. 4, line 50 to col. 5, line 20; combined 
bandwidth processing) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises : 

calculating bandwidth for the signaling message (see col. 4, line 50 to col. 5, line 20; see 
col. 14, line 1-25; see col. 18, line 45-65; computing/calculating bandwidth for the 
demand/request message/data) 
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determining whether calculated bandwidth exceeds a requested bandwidth (see col. 4, 
line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking 
whether calculated/determined bandwidth exceed the SLA bandwidth), and 

determining that the condition is satisfied for the aggregate bandwidth limit feature when 
the calculated bandwidth is determined to not exceed the requested bandwidth (see col. 4, line 50 
to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65; determining/checking whether 
traffic condition is met/accepted for the combined bandwidth processing when the 
calculated/determined bandwidth is not exceed the request bandwidth (i.e. bandwith within 
SLA); 

a connection path being established when the policy condition for each policy feature, of 
the one or more pohcy features identified by the policy for the calling party is determined to be 
satisfied (see FIG. 4, estabhshing a connection/communication base on determination that 
policy/rule status/condition is satisfied/meet for the policy/rule feature identified/recognized by 
the policy of the caUer/user; see col. 13, line 60 and col. 18, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide ''appropriate service logic", as taught by Gai in the system of 
Buyukkoc, so that it would ability to allocate network services and resources by applying high- 
level quality of service pohcies; see Gai col. 5, line 45-55. 

Neither Buyukkoc nor Gai exphcitly disclose ''authorized for use ". 

However, determining the maximum bandwidth allowable for a particular port authorized 
for use by said party is well known in the art of ATM. In particular. Smith teaches determining 
the maximum bandwidth allowable for a particular port authorized for use by said party (see 
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FIG. 1-2; see col. 9, line 5-45, and abstract; determining predetermined/allowable/authorized 
bandwidth for a particular port/connection of end station). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to determining predetermined/allowable/authorized bandwidth for a 
particular port/connection of end station, as taught by Smith in the combined system of 
Buyukkoc and Gai, so that it would cause the system control means to allocate a predetermined 
bandwidth and balance the bandwidth; see Smith col. 2, line 35-67; col. 9, line 21-25. 

Buyukkoc, Gai, and Smith do not explicitly disclose 

identifying an available forward bandwidth from the ingress switch to the egress switch, 
identifying an available reverse bandwidth from the egress switch to the ingress switch, 
calculating a first requested bandwidth associated with the first signaling message, where the 
first requested bandwidth includes a first forward requested bandwidth from the ingress switch to 
the egress switch and a first reverse requested bandwidth from the egress switch to the ingress 
switch, 

calculating a second requested bandwidth associated with the second signaling message, where 
the second requested bandwidth includes a second forward requested bandwidth from the ingress 
switch to the egress switch and a second reverse requested bandwidth from the egress switch to 
the ingress switch, 

determining that the available forward bandwidth exceeds the first forward requested bandwidth 
and that the available reverse bandwidth exceeds the first reverse requested bandwidth, 
determining an occurrence of at least one of: 
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a total forward requested bandwidth, including the first requested forward bandwidth and the 
second requested forward bandwidth, exceeds the available forward bandwidth, or 
a total reverse requested bandwidth, including the first requested reverse bandwidth and the 
second requested reverse bandwidth, exceeds the available reverse bandwidth, determining that 
the pohcy condition is satisfied for the aggregate bandwidth limit feature for the first signaling 
message, and 

determining that the policy condition is not satisfied for the aggregate bandwidth limit feature for 
the second signaling message, and 

forwarding, to the ingress device, a connection failure notice related to the second signaling 
message. 

Ise discloses 

identifying an available forward bandwidth from the ingress switch to the egress switch (column 
4 lines 61-67 remaining resources on route from ingress to egress node), 
identifying an available reverse bandwidth from the egress switch to the ingress switch (Figure 
18 and column 18 lines 62-67 egress edge node transmits the remaining bandwidth), 
calculating a first requested bandwidth associated with the first signaling message, where the 
first requested bandwidth includes a first forward requested bandwidth from the ingress switch to 
the egress switch and a first reverse requested bandwidth from the egress switch to the ingress 
switch (column 4 lines 30-52 shows carrying out admission control for a request for allocation of 
resources for a flow belonging to a set of flows i.e. multiple signaling messages and the request 
for resources is the bandwidths). 
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calculating a second requested bandwidth associated with the second signaling message, where 
the second requested bandwidth includes a second forward requested bandwidth from the ingress 
switch to the egress switch and a second reverse requested bandwidth from the egress switch to 
the ingress switch (column 4 lines 30-52 shows carrying out admission control for a request for 
allocation of resources for a flow belonging to a set of flows i.e. multiple signaling messages and 
the request for resources is the bandwidths), 

determining that the available forward bandwidth exceeds the first forward requested bandwidth 
and that the available reverse bandwidth exceeds the first reverse requested bandwidth (column 4 
lines 30-52 shows judging whether or not to accept the request according to requested resources 
and available resources, column 4 lines 53-60 shows checking whether the remaining resources 
are sufficient i.e. exceed, column 18 lines 14-21 shows for the reverse path check the egress node 
determines if the reservation is smaller than available resources), 
determining an occurrence of at least one of: 

a total forward requested bandwidth, including the first requested forward bandwidth and the 
second requested forward bandwidth, exceeds the available forward bandwidth (column 4 lines 
30-52 shows judging whether or not to accept the request according to requested resources and 
available resources, column 4 lines 53-60 shows checking whether the remaining resources are 
sufficient i.e. exceed, column 18 lines lines 14-21 shows for the reverse path check the egress 
node determines if the reservation is smaller than available resources, column 18 lines 9-14 
shows the remaining bandwidth would be updated to include the first message when using the 
second), or 

a total reverse requested bandwidth, including the first requested reverse bandwidth and the 
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second requested reverse bandwidth, exceeds the available reverse bandwidth, determining that 
the pohcy condition is satisfied for the aggregate bandwidth limit feature for the first signaling 
message (column 4 lines 30-52 shows judging whether or not to accept the request according to 
requested resources and available resources, column 4 lines 53-60 shows checking whether the 
remaining resources are sufficient i.e. exceed, column 18 lines lines 14-21 shows for the reverse 
path check the egress node determines if the reservation is smaller than available resources, 
column 18 lines 9-14 shows the remaining bandwidth would be updated to include the first 
message when using the second) , and 

determining that the policy condition is not satisfied for the aggregate bandwidth limit feature for 
the second signaling message (column 18 lines 14-21 judge whether to accept the request or not 
based on whether the resources are available or not), and 

forwarding, to the ingress device, a connection failure notice related to the second signaling 
message (column 18 lines 61-67). 

Therefore it would have been obvious to one of ordinary skill in the art at the time of the 
invention to combine the previous combination of Buyukkoc and Gai with the aggregate 
bandwidth limit feature of the forward and reverse direction taught by Ise. 
The rationale to combine would be to determine that the whole route would be able to handle the 
needed bandwidth requirement before accepting the call request. 

Regarding claim 15, Buyukkoc discloses where the signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 
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Regarding claims 16, 18, 43 and 45, Buyukkoc discloses where the signaling message 
comprises an Add Party or setup message (see FIG. 8, steps 820,830; a message which contains a 
new call requesting for a route is the SETUP/adding party message in ATM signaIing/SS7; see 
col. 19, line 19-31; see col. 20, line 46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

Regarding claim 31, the combined system of Buyukkoc and Gai discloses all limitation 
of claim 3 1 as set forth in claim above. Buyukkoc discloses a service class selection feature for 
specifying a service class with respect to a network port used by said party (see col. 10, line 50- 
55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 

Regarding claim 42, Buyukkoc discloses wherein the signaling message comprises a 
Connect message (see FIG. 8, step 850, a message which contains a route for new call is the 
connect message in ATM signaling/SS7; see col. 19, line 19-25, 40-45; see col. 20, line 39-45). 

Regarding claim 58, the combined system of Buyukkoc and Gai discloses all limitations 
as set forth in claims above. Buyukkoc further discloses a service class selection feature for 
specifying a service class with respect to a network port used by said party (see col. 10, line 50- 
55; see col. 18, line 26-45; see FIG. 9, trunk/port 932; see col. 20, line 1-10; selecting a class-of- 
service for a port/link/trunk/circuit used by the call). 
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10. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai in view of Ise and VanDervort (US005761 191A), or Horn (US005276676A). 

Regarding claim 10, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party, comprises a maximum size limit 
(see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call are blocked) 
and where the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow. Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether a size in the signaling message exceeds a limit (see col. 14, line 10- 
7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; determining/checking if the 
acceptable size/load/capacity in the new call exceed threshold) , and 

determining that the policy condition is satisfied for the maximum size limit feature when 
the size does not exceed the limit (see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to 
see col. 21, line 30; determining the condition/status (e.g. red, yellow, green) is met/satisfied for 
the acceptable/maximum load/size/bandwidth when it does not exceed threshold). 

Gai also discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party, comprises a maximum size limit and where the determining 
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whether a policy condition associated with each policy feature is satisfied comprises: 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see FIG. 4- 6, and 7A; see col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai exphcitly disclose ''burst". 

However, ATM network having a rule/policy/policing attribute burst size 
threshold/limiting for ATM flow control is well known in the art. 

In particular, VanDervort teaches a maximum burst size limit/threshold feature; 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see col. 6, line 8-11; limited/maximum burst size limit/threshold of user cell 
transmission for policing). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst", as taught by VanDervort in the combined system of 
Buyukkoc, Ise, and Gai, so that it would control the flow of traffic and maximize the utilization 
of network resources; see VanDervort col. 6, line 1-3. 

In particular, Horn teaches a maximum burst size limit/threshold feature and determining 
that the condition is satisfied for the maximum burst size limit feature when the burst size does 
not exceed the limit (see col. 2, line 29-30; maximum burst length is limited by threshold). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "burst", as taught by Horn in the combined system of 
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Buyukkoc, Ise, and Gai, so that it would avoid overflow problem due to long bursts; see Horn 
col. l,Iine 25-34. 



1 1 . Claim 13 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai in view of Ise and Basso (US006633539B1). 

Regarding claim 13, Buyukkoc discloses one ore more policy features, identified by the 
policy for the calling party, comprises an maximum call limit feature (see col. 17, line 30-40; see 
col. 13, line 45-47; see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow. Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether maximum call limit, if a call is established between the calling party 
and called party, exceeds a requested bandwidth (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table 
VII, VIII; determining/calculating call load/limit/bandwidth is higher/exceed the 
requested/required maximum/acceptable load/limit/bandwidth), and 
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determining that the condition is satisfied for the maximum call limit feature when the 
call does not exceed maximum call of calls (see col. 14, line 10-7 to col. 18, line 45; see col. 19, 
line 25- to see col. 21, line 30; Table VII, VIII; determining that the condition/status (i.e. 
red/yellow) for the acceptable/maximum call load/limit/bandwidth when the call is not 
higher/exceed the accepted/maximum calls). 

Gai also discloses maximum call limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a pohcy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
condition/status related/associated with each pohcy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises: determining whether maximum call limit, if a call is established between the calling 
party and called party, exceeds a requested bandwidth determining that the condition is satisfied 
for the maximum call limit feature when the call does not exceed maximum call of calls (see col. 
4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65). 

Neither Buyukkoc nor Gai exphcitly disclose ''concurrent" . 

However, ATM network having a maximum concurrent call limit/threshed for call 
admission control (CAC) is well known in the art. In particular. Basso teaches a maximum 
concurrent call limit feature (see col. 4, line 25-35; maximum allowed/limit number of 
concurrent connection/call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide ''concurrent" , as taught by Basso in the combined system of 
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Buyukkoc, Ise, and Gai, so that it would control concurrent connections/calls to provide efficient 
protection against signaling congestion; see Basso col. 2, line 35-45. 

12. Claim 17 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai in view of Ise and Smith further in view of Noake (US006751222B1). 

Regarding claim 17, neither Buyukkoc, Gai nor Smith explicitly disclose a release 
message see FIG. 4, determining if a policy condition/status related/associated with each 
policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65). 

However, a release message is well know in the ATM signaling/SS7 in order to 
disconnect the call. 

In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 
8, line 9-39). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc, Smith, Ise, and Gai, so that it would make effective use of a band and the 
respective apparatus by transmitting connection information, and by sending/receiving a release 
message it will notify to stop the cell assembling and disassembling processes; see Noake col. 2, 
line 55-64; col. 8, line 19-24. 
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13. Claims 19-21, 23-26, 46-48 and 50 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Buyukkoc in view of Gai in view of Ise and Smith, and further in view of 
Christie'656 (US006690656B1). 

Regarding claim 19, the combination of Buyukkoc, Gai, Smith, Ise, and Christie'656 
discloses all claimed limitations as set forth in claims above. Buyukkoc discloses accessing said 
ATM network through a particular network port associated with said CPE (see FIG. 9, accessing 
Switch 922 through the trunk/port 932; see col. 20, line 1-10). Christie'656 teaches a source 
address validation for ensuring that said party is an authorized party for accessing the ATM 
network (see FIG. 7; see col. 7, line 9-19, 35-45; checking/validating caller number in ANI for 
verification for accessing ATM network). 

Regarding claim 20, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port (e.g. VPI port) between customer and the network). Christie'656 also 
discloses a Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 21, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

Regarding claim 23 and 50, Buyukkoc discloses where said particular one or more 
policy features, identified by the policy for the calling party, comprises a address validation 
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feature and where the determining whether a policy condition associated with each policy feature 
is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 
14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether 
rule/policy condition/state (e.g. yellow. Red, and green), associated/related with connectively 
information, threshold, quality of service, capacity, or status of loading/congestion, 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection (i.e. load/congestion/priority 
/bandwidth/routes/quality-of-service states/conditions) comprises 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 

determining that the condition is satisfied for the address vahdation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 
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Neither Buyukkoc, Smith nor Gai explicitly disclose ''within a range of authorized 
addresses ", "when the address, associated with the calling party, is determined to be within the 
range of authorized addresses", and "a destination address screening for defining a plurality of 
address to which said party can effectuate said call". 

However, a destination address validation/screening is well known in the ATM 
signaIing/SS7, and a destination address/number vahdation/screening for defining a plurality of 
address/numbers to which said party can effectuate said call is well known in the signaling with 
SCP. 

In particular, Christie'656 teaches a destination address vahdation/screening and a 
destination address screening herein where said particular one or more policy features, identified 
by the policy for the called party, comprises a destination address validation feature (see FIG. 7, 
step 720, 720, 730; pohcy/rule validation/verification identify the called (destination) 
addresses/number/IDs validation; see col. 7, line 5-55; see col. 15, line 30-60) and 

determining whether destination address associated with the called party is within a range 
of authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining whether the 
called address with within a range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range), and 

determining that the condition is satisfied for the destination address validation feature 
when the address, associated with the called party, is determined to be within the range of 
authorized addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the 
status/condition is met/accepted/satisfied for the called ID/number/addresses/ANI is determined 
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to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range); 

a destination address screening for defining a plurality of address to which said party can 
effectuate said call (see FIG. 7; see col. 7, line 9-19, 35-45; see col. 15, line 40-60; see col. 2, 
line 1-15; verifying a dial number from the list of numbers where the call needs to be connected). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to ''within a range of authorized addresses ", "when the address, 
associated with the calling party, is determined to be within the range of authorized addresses", 
and ''validate/verify dial number from the list of number to establish the call", as taught by 
Christie'656 in the combined system of Buyukkoc, Smith, Ise, and Gai, so that it would can 
validate the calls and generate a billing record; see Christie'656 col. 3, line 12-22; col. 7, line 39- 
45. 

Regarding claim 24, the combined of Buyukkoc, Gai and Christie'656 discloses 
destination address screening feature is established for a subscriber to which said calling party 
belongs as set forth above in claim 23. 

Neither Buyukkoc nor Christie'656 explicitly discloses "a group of subscribers'" . 
However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular 
policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device- 
specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a 
destination screening feature for a group of subscribers to which the party belongs (see col. 14, 
line 1-15, 56 to col. 15, line 55; applying destination addressing policy rule to a group of users 
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(see FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a group of subscribers" , as taught by Gai in the combined 
system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claims 25, Buyukkoc discloses wherein the ATM network further comprises: 
the policy server to: identify a policy for the called party, the policy for the called party, the 
policy of the called party include address screening feature as set forth above in claim 14. 
Buyukkoc further determine whether a 

wherein the determining whether a policy condition associated with each address 
screening feature is satisfied with respect to signaling message, where, when determining 
whether the policy condition associated with the source address screening feature is satisfied,(see 
FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, line 67; see 
col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow. Red, and green), associated/related with addressing 
identified/recognized by the rule/policy associated with a call/connection for the user/subscriber 
is met/fulfilled according to a new call/connection): the policy server is to 

determining whether an address associated with the calling party (see col. 3, line 5-65; 
see col. 7, line 50 to col. 16, line 65; determining/checking the call/connection of 
user/subscriber), and 
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determining that the condition is satisfied for the address vahdation feature (see col. 3, 
line 5-65; see col. 7, line 50 to col. 16, line 65; determining that status/condition (i.e. green, 
yellow, red) is met/satisfied for the address checking/verification); 

where the connection path is estabhshed based on whether the condition is satisfied for 
the source address screening feature (see FIG. 8, step 850, 860, 870; see FIG. 10, steps 1045, 
1050, 1055; see col. 14, line 1-65; see col. 19, line 35-50; see col. 21, line 40-50; 
setting/establishing the call/connection when conditions/status address checking/verification is 
met/flilfiUed). 

Gai discloses disclose a address validation/screening and address screening herein 
where said particular one or more policy features, identified by the policy for the calling party, 
comprises address validation feature and where the determining whether a policy condition 
associated with each policy feature is satisfied comprises: determining whether an address 
associated with the calling party, and determining that the condition is satisfied for the address 
validation feature when the address, associated with the calling party (see FIG. 4- 6, and 7A; see 
col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc nor Gai exphcitly disclose "a second policy server", ''within a range 
of authorized addresses ", "when the address, associated with the calling party, is determined to 
be within the range of authorized addresses". 

However, a source address validation/screening is well known in the ATM signaling/SS7. 

In particular, Christie'656 teaches a second policy server (see FIG. 10, second 
call/connection manager (CCM) 1 115/1 120); see col. 20, line 25 to col. 21, line 60) to: a source 
address validation/screening and a destination address screening herein where said particular one 
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or more policy features, identified by the policy for the calling party, comprises a source address 
validation feature (see FIG. 7, step 720, 720, 730; policy/rule validation/verification identify the 
caller is the caller (source) and called (destination) addresses/number/IDs validation; see col. 7, 
line 5-55; see col. 15, line 30-60) and 

determining whether an address associated with the calling party is within a range of 
authorized plurality of addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining 
whether the caller address with within a range of authorized numbers/IDs/ ANIs; note that a 
group or IDs/numbers/addresses/ ANIs stored in the access table is within an accessible range), 
and 

determining that the condition is satisfied for the source address vahdation feature when 
the address, associated with the calling party, is determined to be within the range of authorized 
plurality of addresses (see col. 7, line 5-55; see col. 15, line 30-60; determining the 
status/condition is met/accepted/satisfied for the caller ID/number/addresses/ANI associated with 
the caller is determined to be within range of authorized numbers/IDs/ ANIs; note that a group or 
IDs/numbers/addresses/ANIs stored in the access table is within an accessible range). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a second policy server", ''within a range of authorized 
plurality of addresses ", "when the address, associated with the calling party, is determined to be 
within the range of authorized plurality of addresses", as taught by Christie'656 in the combined 
system of Buyukkoc and Gai, so that it would can validate the calls and generate a billing record; 
see Christie'656 col. 3, line 12-22; col. 7, line 39-45. 
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Regarding claim 26, the combined of Buyukkoc, Gai and Christie'656 discloses source 
address screening feature is established for a subscriber to which said party belongs as set forth 
above in claim 25. 

Neither Buyukkoc nor Christie'656 explicitly discloses "a group of subscribers'" . 
However, Gai teaches a policy server (see FIG. 4, policy server 322) comprising the particular 
policy feature (see FIG. 4, Policy Rule generation engine 414, policy translator 410, and device- 
specific filtering entity; see col. 13, line 61 to col. 14, line 5) including at least one of a 
destination screening feature for a group of subscribers to which the party belongs (see col. 14, 
line 1-15, 56 to col. 15, line 55; applying destination addressing policy rule to a group of users 
(see FIG. 7A, marking users, admin users, executive users, etc.) where a specific user (see FIG. 
7A, John Doe) belongs; see col. see col. 14, line 10-18). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a group of subscribers", as taught by Gai in the combined 
system of Buyukkoc and Christie '5 65, so that it would ability to allocate network services and 
resources by applying high-level quality of service policies; see Gai col. 5, line 45-55. 

Regarding claim 46, the combined system of Buyukkoc, Gai and Christie'656 discloses 
all claimed limitations as set forth in claim 19. Buyukkoc discloses accessing said ATM network 
through a particular network port associated with said CPE (see FIG. 9, accessing Switch 922 
through the trunk/port 932; see col. 20, line 1-10). 
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Regarding claim 47, Buyukkoc discloses wherein said particular network port is a 
Customer Logical Port (see col. 4, line 20-40; see col. 5, line 20-26; edge node/switch provides 
logical connection/port between customer and the network). Christie'656 also discloses a 
Customer Logical Port (see col. 4, line 35-40; 60-67; a logical/virtual port/link). 

Regarding claim 48, Buyukkoc discloses wherein said particular network port is a full 
physical port (see FIG. 9, physical trunk/port 932; see col. 20, line 1-10). 

14. Claims 22 and 49 are rejected under 35 U.S. C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai in view of Ise and Smith and further in view of Farris 
(US006 154445 A). 

Regarding claim 22, Buyukkoc discloses the number of setup messages (see FIG. 8, 
steps 820,830; a message which contains a new call requesting for a route is the SETUP/adding 
party message in ATM signaling/SS7; see col. 19, line 19-31; see col. 20, line 46-52; see col. 20, 
line 39-45; see col. 21, line 19-25). Buyukkoc discloses the number of setup messages as 
described above in claim 18. 

Buyukkoc discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party comprises a call feature (see col. 10, line 50-55; see col. 18, 
line 26-45; call/connection type feature) and where the determining whether a policy condition 
associated with each policy feature is satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 13, line 1-7; 64 to col. 14, line 67; see col. 19, line 25-40; see col. 21, line 19-30; 
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determines/decides whether rule/policy condition/state (e.g. yellow, Red, and green), 
associated/related with connectively information, threshold, quality of service, capacity, or status 
of loading/congestion, identified/recognized by the rule/policy associated with a call/connection 
for the user/subscriber is met/fulfilled according to a new call/connection (i.e. 
load/congestion/priority /bandwidth/routes/quality-of-service states/conditions), comprises: 

determining whether the signaling message result for a customer logical port with which 
the calling party is associated (determine/checking if a requested/demand class of service based 
is not-block (i.e. permitted) for a ATM virtual link with VPI port number on a new call; see col. 
14, line 1 to col. 18, line 66; see col. 19, line 10-55); and 

determining that the condition is satisfied for the call feature when the requested the 
signaling message does not result for the customer logical port with which the calling party is 
associated (determining/checking the condition/status (i.e. red/green/yellow) is met/satisfied for 
type of call when the requested/demand call type is not-blocked (i.e. permitted) for a VPI port 
number on a new party; see col. 14, line 1 to col. 18, line 66; see col. 19, line 10-55). 

Gai also discloses call feature (see col. 3, line 5-60; class/type of service 
selection/choosing) and where the determining whether a policy condition associated with each 
policy feature is satisfied (see FIG. 4, determining if a policy condition/status related/associated 
with each policy/rule feature identified/recognized by the policy/rule for the caller/user is 
accepted/satisfied; see col. 13, line 60 and col. 18, line 65) comprises: 

determining call type feature based on the signaling message (determining/calculating a 
request call type based on request/demand; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40), 
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determining whether the requested call type feature is permitted for a customer logical 
port with which the calling party is associated (determining/calculating if the requested/demand 
call type allowed/permitted for a customer/user logical port/connection (i.e. ATM) with which 
the caller/subscriber is associated/related; col. 3, line 5-65; see col. 5, line 5-45; see col. 11, line 
1 to col. 12, line 40); and 

determining that the condition is satisfied for the call type feature when the requested call 
type feature does not result for the customer logical port with which the calling party is 
associated (determining/checking if the condition/status for traffic is permitted/allow for the 
logic port with which the caUed/user is related; see col. 3, line 5-65; see col. 5, line 5-45; see col. 
11, line 1 to col. 12, line 40). 

Neither Buyukkoc, Smith nor Gai explicitly disclose "a maximum call attempt rate limit." 

However, having a maximum call attempt rate limit/threshold is well known in the 
signaling/SS7. In particular, Farris teaches a maximum call attempt rate limit (see col. 14, line 1- 
12; see col. 11, line 5-17; acceptable/maximum specified rate of call attempts). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "acceptable/maximum specified rate of call attempts", as 
taught by Farris in the combined system of Buyukkoc, Smith, Ise, and Gai, so that it would can 
detect the predetermined events and/or imminence of predetermined events, and then blocking or 
controlling those events from their incipiency; see Farris col. 14, line 1-6. 

Regarding claim 49, the combined system of Buyukkoc, Gai, Smith and Farris discloses 
all claimed limitation as set forth in claim 22. Buyukkoc discloses the number of setup messages 
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(see FIG. 8, steps 820,830; a message which contains a new call requesting for a route is the 
SETUP/adding party message in ATM signaIing/SS7; see col. 19, line 19-31; see col. 20, line 
46-52; see col. 20, line 39-45; see col. 21, line 19-25). 

15. Claims 38, and 65 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai, Ise, Smith, and Basso (US006633539B1). 

Regarding claim 38, Buyukkoc discloses a policy feature comprise a maximum call 
limit feature for specifying the total number of calls allowed concurrently with respect to a 
network port used by said party (see col. 14, line 10 to col. 15, line 50; see FIG. 9, trunk/port 
932; see col. 20, line 1-10; acceptable/allowable total number of calls threshold/limit for a 
trunk/port). Buyukkoc discloses one ore more policy features, identified by the policy for the 
calling party, comprises an maximum call limit feature (see col. 17, line 30-40; see col. 13, line 
45-47; see col. 14, line 15-65; acceptable/maximum call load/limit/bandwidth) and 

wherein the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow. Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 
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determining whether maximum call limit, if a call is established between the calling party 
and called party, exceeds a requested bandwidth (see FIG. 8, step 840; see FIG. 10, steps 1035, 
1040; see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; Table 
VII, VIII; determining/calculating call load/limit/bandwidth is higher/exceed the 
requested/required maximum/acceptable load/limit/bandwidth), and 

determining that the condition is satisfied for the maximum call limit feature when the 
call does not exceed maximum call of calls (see col. 14, line 10-7 to col. 18, line 45; see col. 19, 
line 25- to see col. 21, line 30; Table VII, VIII; determining that the condition/status (i.e. 
red/yellow) for the acceptable/maximum call load/limit/bandwidth when the call is not 
higher/exceed the accepted/maximum calls). 

Gai also discloses maximum call limit feature (see col. 4, line 50 to col. 5, line 20; 
combined bandwidth processing) and wherein the determining whether a pohcy condition 
associated with each policy feature is satisfied (see FIG. 4, determining if a policy 
condition/status related/associated with each pohcy/rule feature identified/recognized by the 
policy/rule for the caller/user is accepted/satisfied; see col. 13, line 60 and col. 18, line 65) 
comprises: determining whether maximum call limit, if a call is established between the calling 
party and called party, exceeds a requested bandwidth determining that the condition is satisfied 
for the maximum call limit feature when the call does not exceed maximum call of calls (see col. 
4, line 50 to col. 5, line 20; see col. 14, line 1-25; see col. 18, line 45-65). 

Neither Buyukkoc, Smith nor Gai explicitly disclose ''concurrent" . 

However, ATM network having a maximum concurrent call limit/threshed for call 
admission control (CAC) is well known in the art. In particular. Basso teaches a maximum 
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concurrent call limit feature (see col. 4, line 25-35; maximum allowed/limit number of 
concurrent connection/call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide ''concurrent" , as taught by Basso in the combined system of 
Buyukkoc, Smith, Ise, and Gai, so that it would control concurrent connections/calls to provide 
efficient protection against signaling congestion; see Basso col. 2, line 35-45. 

Regarding claim 65, the combined system of Buyukkoc, Gai and Basso discloses all 
claimed limitation as set forth in claim 38 above. 

16. Claims 27-29 and 54-56 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc, Gai, Ise, and Smith, in view of Kobayashi (US 5,896,371). 

Regarding claims 27, Buyukkoc discloses wherein where said particular one or more 
policy features, identified by the policy for the calling party, comprises a maximum size limit 
(see col. 14, line 15-65; acceptable/maximum load/size/bandwidth before the call are blocked) 
and where the determining whether a policy condition associated with each policy feature is 
satisfied (see FIG. 8, step 840; see FIG. 10, steps 1035, 1040; see col. 13, line 1-7; 64 to col. 14, 
line 67; see col. 19, line 25-40; see col. 21, line 19-30; determines/decides whether rule/policy 
condition/state (e.g. yellow. Red, and green), associated/related with connectively information, 
threshold, quality of service, capacity, or status of loading/congestion, identified/recognized by 
the rule/policy associated with a call/connection for the user/subscriber is met/fulfilled according 
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to a new call/connection (i.e. load/congestion/priority /bandwidth/routes/quality-of-service 
states/conditions) comprises: 

determining whether a size in the signaling message exceeds a limit (see col. 14, line 10- 
7 to col. 18, line 45; see col. 19, line 25- to see col. 21, line 30; determining/checking if the 
acceptable size/load/capacity in the new call exceed threshold) , and 

determining that the condition is satisfied for the maximum size limit feature when the 
size does not exceed the limit (see col. 14, line 10-7 to col. 18, line 45; see col. 19, line 25- to see 
col. 21, line 30; determining the condition/status (e.g. red, yellow, green) is met/satisfied for the 
acceptable/maximum load/size/bandwidth when it does not exceed threshold). 

Gai also discloses wherein where said particular one or more policy features, identified 
by the policy for the calling party, comprises a maximum size limit and where the determining 
whether a policy condition associated with each policy feature is satisfied comprises: 
determining whether a burst size in the signaling message exceeds a limit, and determining that 
the condition is satisfied for the maximum burst size limit feature when the burst size does not 
exceed the limit (see FIG. 4- 6, and 7A; see col. 9, line 58 to col. 20, line 30). 

Neither Buyukkoc, Smith nor Gai explicitly disclose ''burst-sized request". 

However, limiting a burst-size request is well known in the art of ATM. In particular, 
Kobayashi teaches a maximum burst size limit feature for limiting a burst-size request associated 
with said call (see FIG. 6; see col. 12, line 55 to col. 13, line 35; a limiting/setting/changing the 
number of cells transmitted in each call). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide ''burst-sized request", as taught by Kobayashi in the 
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combined system of Buyukkoc, Smith, Ise, and Gai, so that it would provide a flow control 
performed cooperatively by the network and the terminal equipment and call accepted control is 
simplified; see Kobayashi col. 7, line 46-52; col. 8, line 40-45. 

Regarding claim 28, the combined system of Buyukkoc, Gai, Smith and Kobayashi 
discloses all claimed limitations. Kobayashi discloses the number of packets per second allowed 
to be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 
to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call 
to ATM network). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc, Smith and Gai, for the 
same motivation as above in claim 27. 

Regarding claim 29, the combined system of Buyukkoc, Gai , Smith and Kobayashi 
discloses all claimed limitations. Kobayashi discloses the number of packets per second allowed 
to be received by said party from said ATM network with respect to said call (see FIG. 6; see 
col. 12, line 55 to col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to 
received in each call from ATM network). Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to provide the number of packets per 
second requested to be received, as taught by Kobayashi in the combined system of Buyukkoc, 
Smith, Gai, for the same motivation as above in claim 27. 
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Regarding claim 54, the combined system of Buyukkoc, Gai , Smith and Kobayashi 
discloses all claimed limitations as set forth in claim 27 above. 

Regarding claim 55, Kobayashi discloses the number of packets per second allowed to 
be transmitted to said ATM network with respect to said call (see FIG. 6; see col. 12, line 55 to 
col. 13, line 35; a number of cells per second (i.e. 10Mbps) requested to transmit in each call to 
ATM network). Therefore, it would have been obvious to one having ordinary skill in the art at 
the time the invention was made to provide the number of packets per second requested to be 
transmitted, as taught by Kobayashi in the combined system of Buyukkoc, Gai and Smith, for the 
same motivation as above in claim 27. 

Regarding claim 56, Kobayashi discloses the number of packets per second allowed to 
be received by said party from said ATM network with respect to said call (see FIG. 6; see col. 
12, line 55 to col. 13, line 35; a number of ceUs per second (i.e. 10Mbps) requested to received in 
each call from ATM network). Therefore, it would have been obvious to one having ordinary 
skill in the art at the time the invention was made to provide the number of packets per second 
requested to be received, as taught by Kobayashi in the combined system of Buyukkoc, Gai and 
Smith, for the same motivation as above in claim 27. 

17. Claims 32-37 and 59-64 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Buyukkoc in view of Gai, Ise, Smith and Kilkki (US006041039A). 
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Regarding claims 32-37, the combined system of Buyukkoc, Gai and Smith discloses 
service class as described above in claim 31 and 58. Buyukkoc further discloses constant bit rate 
service (CBR) and variable bit rate service (VBR) (see col. 1, line 50-60). 

Neither Buyukkoc, Gai nor Smith explicitly discloses, "real-time VBR service, non-real 
time VBR, unspecified bit-rate (UBR), and available bit-rate (ABR) ". 

However, the ATM class of services a real-time VBR service, non-real time VBR, 
unspecified bit-rate (UBR), and available bit-rate (ABR) is well known in ATM standard. In 
particular, Kilkki teaches CBR, VBR, a real-time VBR service, non-real time VBR, unspecified 
bit-rate (UBR), and available bit-rate (ABR) (see col. 1, line 54-67). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide quality of service class defined by ATM standard, as taught 
by Kilkki in the combined system of Buyukkoc, Gai, Ise, and Smith, so that it would provide a 
capability to manage increases in network load, supporting both real-time and non-real time 
application, and offering, in certain circumstances, a guaranteed level service quality; see Kilkki 
col. 1, line 44-53, also by using the ATM standard services, it will enable the service provider to 
interoperate between multi-vendor networks. 

Regarding claims 59-64, the combined system of Buyukkoc, Gai, Ise, and Smith 
discloses all claimed limitations as set forth in claims 32-37 above. 

18. Claim 44 is rejected under 35 U.S.C. 103(a) as being unpatentable over Buyukkoc in 
view of Gai in view of Ise in view of Smith, and further in view of Noake (US006751222B1). 
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Regarding claim 44, neither Buyukkoc nor Gai explicitly disclose a release message. 
However, a release message is well know in the ATM signaIing/SS7 in order to disconnect the 
call. In particular, Noake teaches a release message (see FIG. 4, RELEASE message; see col. 8, 
line 9-39). Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to provide a release message, as taught by Noake in the combined 
system of Buyukkoc, Gai, Ise, and Smith so that it would make effective use of a band and the 
respective apparatus by transmitting connection information, and by sending/receiving a release 
message it will notify to stop the cell assembling and disassembling processes; see Noake col. 2, 
line 55-64; col. 8, line 19-24. 



Conclusion 

19. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to CHRISTOPHER Ray CROMPTON whose telephone number is 
(571)270-3678. The examiner can normally be reached on Monday-Thursday 2-5 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor. Derrick W. Ferris can be reached on 571-272-3 123. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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Examiner 
Art Unit 2463 
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